This chapter provides an overview and a general description of the data management architecture of the Containers Library. It introduces the components of the library, including the base container objects and the cursors, and how they relate to each other. It also defines the general concepts used throughout this manual.
The Containers Library architecture
The Containers Library provides two sets of objects that will allow you to quickly and easily incorporate powerful data management capabilities into your applications: the containers and the cursors. Containers are the objects that handle all the actual structuring and management of the data, and provide methods for accessing data directly from a data source (e.g., a B+ tree on a disk file). By using the containers, you can effectively hide from your applications all the details of how the data is structured or stored. Cursors provide an even greater level of abstraction by hiding all the details of the data. When using a cursor, an application does not need to know how a particular data item is formed (i.e., if it is a record, an object or a simple type like a string or an integer) or how is the data structured within a data source. This last level of abstraction in a cursor is provided by the container objects, though you can also implement a new cursor that handles itself all the management of the data instead of using a container. This is not recommended, however, since it would limit the flexibility of the objects and of the application in general.
The diagram in Figure 1.1 provides a general overview of the data management architecture of the Containers Library.
( see fig1_1.gif)
The following sections describe the parts of the diagram in greater detail.
What is data?
A data source is a set of information that has the same structure and is stored as a unit. For example, a data source can be a binary tree stored in conventional memory, a collection stored in expanded memory or a table stored in a file on disk.
Data is any information stored in a data source. It can be a single field, a record that consists of a series of fields, or a set of records.
What is data access?
Data access is the process of retrieving or storing data in a data source. The Containers Library provides objects that let you add efficient data access functionality into your applications. As shown in Figure 1.1, there are two levels of abstraction provided in the library for accessing the data in a data source:
Containers provide access to the data directly. They handle all the data structuring details and the storing of the data in the selected storage media. By using a container, an application does not need to know how the data is structured or where it is stored. In the diagram, containers are represented by the TSequence and TGraph objects, which are the base objects for all containers in the library and are described later in this chapter.
Cursors hide all the details of the data and use the containers for accessing the data. By using a cursor, an application does not need to know anything about the data being accessed, except for its type (e.g., string, long integer, boolean, etc.). All the information about the data is hidden by the container and cursor objects.
You will never need to access the data directly and instead, you should always use a container or a cursor for this purpose. You can still do so if you know how is the data stored and structured within a data source. However, this would bind your code to a particular data type and structure, making it impossible to modify the underlying data requirements without having to modify a large portion of the code also.
The base object: TContainer
TContainer is the starting point of the Containers Library object hierarchy. Except for a few objects derived from Borland's TCollection object, all containers are ultimately derived from TContainer. It provides methods that are completely independent of the data structure being used. TContainer includes methods for inserting items, deleting items, performing an action on some or all of the items in a container, etc.
However, TContainer is an abstract object that provides no data structuring functionality. This is the reason that TContainer is not shown in Figure 1.1. Instead of using a TContainer directly, you will always use any of the linear or a non-linear containers that descend from the two base objects shown in the diagram: TSequence and TGraph.
Linear containers
A linear container is a container that implements a linear or sequential data structure. All linear containers are derived from TSequence, a base abstract object that provides the interface used by all linear containers in the library.
Linear data structures
A linear data structure is a structure in which for each element, there is a "next" element, as shown in Figure 1.2.
( see fig1_2.gif)
In a linear data structure, each item is logically stored one after another, forming a sequence of elements. Depending on the data structure, however, elements are not always physically stored together. For example, elements in a linked list can be stored anywhere in memory. The linearity of the list is maintained by storing in each element a pointer to the next element in the sequence.
Every element in a linear data structure can be uniquely identified by a discrete value (e.g., 0, 1, 2, 3, . . ., n) that indicates its position in the sequence relative to other elements. This value is called the index of an element. In Figure 1.2, each element has a unique index value starting at index 0. Linear data structures allow you to quickly access specific data items, simply by specifying their position in the structure.
Linear data structures include arrays, collections, tables, linked lists, stacks and queues.
The function of TSequence
TSequence declares all the methods used by linear containers to provide access to data items by using their index values. For example, by using the methods in TSequence, you can easily insert an item at index 15, delete the item at index 20, or update an item stored at position 7. However, TSequence is an abstract object that provides very little data structuring functionality, so you will never need to create an instance of this object. Instead, you will always use a descendant container like TList or TTable.
In Figure 1.1, TSequence represents linear containers in general. This means that you can replace the TSequence object in the diagram with any other sequential container in the library, and nothing else in the diagram will change. In your applications, this translates to being able to use references to the abstract object type TSequence instead of using specific data structure types. This way, you can later change the linear structure that you are using without having to typecast all references to it to the new object type.
Sorted linear containers
There are also several specialized containers that will sort the data in the sequence by key. These containers provide access to the data in key order as well as in sequential order (i.e., by index number). Often, however, sorting a linear container involves relocating small to large amounts of data, which is not desired in all cases in which indexed access to the data is required. Depending on the application, a graph (or non-linear container) might be a better alternative to a sorted linear container.
Non-linear containers
A non-linear container is a container that implements a non-linear data structure. All non-linear containers are derived from TGraph, a base abstract object that provides the interface used by all non-linear containers in the library.
Non-linear data structures
A non-linear data structure is a structure in which for each element, there can be many "next" elements, as shown in Figure 1.3. This definition introduces the concept of ramification structures, which include the structures generally known as graphs and trees.
( see fig1_3.gif)
A graph is a set of points and lines, with each line joining one point with another (Figure 1.3 is also an example of a graph). The points are called the nodes of the graph and the lines are called the sides of the graph. A side is determined by the points it connects. For example, side 3 connects points b and d, and it is said to be of the form (b, d). A graph is completely defined by its set of nodes and sides.
A tree is an important class of graph that is simple (i.e., it has no cycles and there are no more than one side joining a pair of nodes) and connected (i.e., it cannot be split into two graphs without eliminating at least one side). Since there no general graphs implemented in the library, we'll focus our discussion of non-linear containers exclusively to the tree structures.
Items in a tree are always sorted by key. A key is something that uniquely identifies an item in a data set. You can quickly retrieve items from a tree simply by specifying their key value. Search times are usually much smaller than when making searches in a linear container, making trees ideal structures for providing indexed access to your data. However, they are also more complex structures and some require more system resources than do most of the linear containers.
The function of TGraph
TGraph declares all the methods used by non-linear containers to provide access to data items by using their key value. For example, TGraph lets you easily retrieve the first item that has the key 'Smith', delete all items in the container with that have the key 'Doe' or update the data of all items that have the key 'Loomis'.
However, just like TContainer and TSequence, TGraph is an abstract object that provides very little data structuring functionality, so you will never need to create an instance of this object. Instead, you will always use a descendant container like TBinaryTree or TBPlusTree.
In Figure 1.1, TGraph represents non-linear containers in general. As with TSequence, this means that you can replace the TGraph object in the diagram with any other non-linear container in the library, and nothing else in the diagram will change. In your applications, this translates to being able to use references to the abstract object type TGraph instead of using specific data structure types.
Cursors
Cursors are objects that provide an interface to all the data management aspects of an application. They hide all the details of how the data is formed, how is it structured within a data source or where is it stored, so that changes in the management of the data do not affect other areas of your code. This encapsulation of details allows you to easily write flexible data-independent applications.
Cursors let you clearly delineate the boundaries between the code for managing your data, and the code for displaying it. By using the cursors' interface, you do not have to worry about making your browsers or data-controls dependant on a particular data type. The way the data is managed and how is it displayed in your control are clearly separated when using a cursor. If you need to change the underlying data structure, all you have to do to use your data-control with the new data structure is to create a new TCursor descendant that knows how to access it.
TCursor is the base object type for all cursors. Since it is an abstract object type, you will never need to create an instance of TCursor. Instead, you will always use a particular descendant cursor, depending on the data structure that you are using. For example, if you want to use your data control with a TTable, you will use the TTableCursor.
Cursors also provide the required functionality to allow you to write data-aware controls. A data-aware control is an object of the user interface that will react to changes in the underlying data set.
What are data controls?
Data controls are elements of the user interface that let the user view and modify the data in a data source. For example, an input line that displays the value of a field in a table and allows the user to modify the value of that field. The Containers Library does not include any data controls, but provides all the components necessary to implement efficient data-independent and data-aware controls.
Data-aware controls are controls that react to changes in the data. For example, a data-aware control can update itself if it detects that the position of a cursor in a given data set has changed. This is useful if you want to use different data controls for modifying different parts of the same data items simultaneously.
Putting it all together
All parts of the Containers Library are closely related to each other. When used together, they provide the greatest flexibility for managing your data.
As shown in figure 1.1, a container can have several different cursors accessing it simultaneously. This makes it possible for you to have simultaneous views of different areas of a data source, without having to create several copies of the data. A cursor can also have many data controls accessing it at the same time, which is useful when you want to synchronize several data-aware controls to simultaneously access the same record in a data set.
Depending on the flexibility that you need, you can choose to either use the containers directly or access them through a cursor. In some cases, accessing a container through a cursor provides easier access to your data (as with tables, for example) while in some others, you may need the additional flexibility of the containers' methods.
In the following chapters, you will learn how to use the methods in the containers' interface. Once you have a good understanding of the programming interface used by containers, you can move on to learning the specifics of particular groups of data structures and their respective container objects. This will give you the tools necessary for using the containers and for choosing the most appropriate data structure for any given application. The last chapters of the manual provide detailed documentation of cursors, and how to use them with the container objects.
